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ABSTRACT 

"V v The Structured Planning and, Debugging Editor (SPADE) 

is j%. new kinfl of interactive programming- ^n?ironient in which , 
computer programs are generated Jt> y explicitly articulating planning 
decisions, ^he design of SPADE is based upon the -development of a 
grammar of -plans from a taxonomy of f basi^c planning techniques. The 

•utility of this approach to. program definition is that a record' of 
planning decisions, called the plan derivation, provides guidance for f 
subsequent modification or debugging of the program. Moreover, this 

.grammatical approach to planning allows the development k taxonofy 
of bugs, as particular kinds of errors in^ajfclying the planning 
grammar. Following a linguistic analog** fiV* types of^planning bugs ) 
are characterised: syntactic, semantic, pragmatic, cirOTaipcutions-, 
and slips of the tongue. The plan derivation can be accessed during 
subsequent debugging to aid in diagnosing the underlying cause »of 
erroneous code. Repair is accomplished via replannihg, . in wlfcch a' 

""substructure of the derivation is replaced^. The design of. a debugging 
assistant for the SPADE environment called RAID is based on this 
theory. Thirty references are listed. (Auth<^r/LLS) s V_ 
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A grammar of plans. Is developed from a taxonomy of basic 
planning techniques. This grammar sVves as the basis for the design of 
a* new kind of Interactive programing, environment (SPADE) , in which 
progress are generated by explicitly articulating planning decisions. 
The utlli«j of this approach to program definition is that a record of 
these depUions, called the plan derivation, provides guidance for 
subsequent modification or, debugging of the program. 

Horeover, this grammatical approach to planning allows the 
.development of a- taxonomy of bugs, as particular kinds of -errors in 
applying the planning grammar. Following a linguistic, analogy, fivm 
types of planning bug's are characterized: syntactic, semantic 
pragmatic, circumlocutions, and slips of the tongue. The plan derivation 
can be accused during subsequent debugging, to aid in diagnosing the 
underlying cause of erroneous code. Repair Is accomplished via 
replanning. in which a substructure of the derivation 1* replaced. A 
debugging assistant for the SPADE environment (RAID) is designed based on 
this theory. 

The enterprise embodies Dijhstra's. philosophy Of programming in 
a structured 'f-ashion, but represents a. more detailed study of planning 
and debugging techniques than- has previously been attempted. 



* This report describes research done at the Artificial 'Intelligent 
^ Laboratory of the Massachusetts Institute of Technology. It was supported in 
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\ A Naval Research contract N000l4-7«-C-0643\ and In part by the Division for Study 

«T and Research in Education.. Massachusetts Institute of Technology. 
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1. Introduction „ ■ .+ 

( . • 

•'••*•. - .. .. ' « • 

V 

' 1/1. Background and Objectives 

i - .... 

Our goal* in this report art: (1) to understand the processes by which a 
programmer, whether human or machine, moves from a declarative statement of a 
problem to a procedural statement of its solution; and (2) to discover methods 
by which these processes can 1>e facilitated. , We see programming as involving' two 
principle activities: planning arid' debugging. * Host previous research has 
studied these two activities In an isolated fashion. This report presents a. 
unified theory of planning and debugging, based oh a linguistic analogy. 

• / • 

The investigation ' includes the design of ^an interactive programming 
environment called SPADE. SPADE is an 'acronym for Structured Planning and 
Debugging Editor, this name emphasizes two themes; (1) ouf perspective on, 
programming as a process of planning and debugging; and (2) ourjixpectat ion - that 
SPA0fe L like systems will eventually help In achieving the structured programming 
■ovtamt's goals of program reliability, readitfmityj extensibility, portability, 
and so on. The objectives for the SPADE programming environment at** that it 
serve, mot only as a practical application of the theory, but also as an 
experimental crucible for testing claims. of the theory. 1 ) \ 

, In other papers the authors elaborate other dimension* of this linguistic 
approach to' problem solving. [Killer & Goldstein 1970s] provides an overvie* of 
ouf research as a wbole. [Goldstein a HilJ^f 1976a] presents a long term 
research direction: applying the problem solving theory to the construction of a 
learning environment to teach elementary,, programming. In [Goldstein ft 
Hlller 1976b] the authors design PATN, an automated problem solver. In [Hillefr ft 
Goldstein 1976b] the authors- consider the use. of grammars in the analysis of 
elementary programing protocols. In (Miller ft Goldstein 1976d} the^auttyQrs. take 
kteps toward automating* this analysis task by designing a system called PAZATN. 



1,2. Overview 

The basis for^ SPADE'S design is a unified problem solving theory which 
incorporates a, fundamental, linguistic analogy. The theory rests on a taxpnomy of 
basic planning techniques: Planning/ according to the thedry, proceeds by ft 
sequence of design decisions, in which the programmer ieltcts a plan type, and 
then carries* j>ut the subgbals defined by the application of that plan type* to the 
current problem situation*. This decision process is modeled by a context frfte 

* Thi* analysis of planning leags to a taxonomy of program bifgs as will. 
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Our claim that th« theory unifies plannin) and debugging is based on the fact 
that* classes of bugs are defined by tracing their origins to particular types bf 
erroneous decisions in applying the planning grammar. Following a linguistic 
analogy, these planning bugs are characterized as: syntactic, semantic, 
pragmatic, circumlocutions, and slips of the tongue. ' ' . «■ 

« */ 
The SPADE System will provide an interpreter for cdntext free grammar 
rules. • I't will provide bookkeeping facilities. maintaining a- record of the 
plannirig decisions made in the application of each rule. This data structure 
generated by the* graaaar is called the pies derivation. Programs are merely the 
terminal strings of such derivations. HenpersSPADE should encourage programmers 
to/articulate their planning decisions, father than merely leaving the plan 
implicit in the resulting code. . 

The derivation- structure created during planning episodes can bo accessed 
during subsequent debugging episodes to aid in diagnosing the underlying causa of 
malfunctioning- code. Repair would then proceed via replanning, in which a 
substructure of the plan derivation is replaced. One result of this repair would 
be that the purely hierarchical derivation tree is replaced by a caert Of 
alternative derivation trees. Diagnosis and repair techniques based on tfil* 
theory are to be implemented in a debugging assistant called RAID (for RAtional 
Implementation of Debugging). RAID will be a component of the SPADE environment. 

? . • 

This paper presents the design for SPADE. We plan to implement the 
>ystem. The implemented system will serve as the basis for a set Of experiment!* 
exploring aspects of the theory, such as the relative effectiveness of 
alternative planning grammars. Examination of session transcripts coupled with 
systematic interviews of SPADE users will provide** evidence >or answering the 
following sorts of question*: 

\ . • «• / • 



1. Do users find the planning grammars adequate; or are there 
planning ^decisions which siaply cannot be made given the 
, restrictions of .the grammar? 



2. How much of the granmar would reaain the same in moving from 
one application tb another? We initially plan to implement the 
domain dependent* portion of the grammar for the Logo .elementary 
grapnteaDrogramminB domain. 2 Later we intend experimenting with 
fanning grammars for different domains, to include: the 
'■blocks world,", a set theory world, and an elementary calculator 
world. 3 

3*. Do the plan derivation structures generated' by the grammar 
serve as useful documentation, aiding one programmer in 
understanding and modifying programs written by another? 
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.4. How effective is tht systen as a pedagogical alternative for 
teaching, programing and'preblea solving? Can Its effectiveness 
be. attributed to such factors as greater. articulation of 

' planning and debugging strategies? 4 

* » , ' * 

The answers jto these questions; In turn, will shed light upon a ^larger 
question addressed by the enterprise: does computational linguistics provide a 
valuable set of foraal' concepts and alforlthas for constructing a theory of 
problea solving? • , ' £ 

• 

Section two. presents our theory of planning. The third section 
Introduces $he SPADE systen. puf theory* of debugging • and Its onbodlaent in 
RAID, are the topics of sections four and five. We conclude by discussing 
limitations, extensions i and applications to structured progressing, autoeMtlc 
progressing, and protocol' analysis. 

. . V > • ^ 



/ 
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2. A Grammatical Theory of Planning , . 

It would Mielp ■ great deal if^we had a general language * . ' «" 

*P«clally designed for talking about Plans Such a language \^ 

would, presumably, give us a convenient- notation for su.ch 
aspects as flexibility 1 of Plans, the substitution of subplans, 
f conditional and preparatory subplans, etc. For example, It does 
not particularly patter in what order Brs. Jones "chooses to run 
her- errands when she gets tb .town. The ..." subplans can be 
permuted in order, and so we say that this part of her Plan is- 
' flexible. But she cannot permute the order of these with the 11 

sybplan for driving to town, or for driving hose. That part' of 
the plan *s inflexible. Some subplans are executed solely for 
^ the purpose of creating the conditions under^ which another 
subplan is relevant:' Such preparatory or mobilizing subplans 
cannot be froely moved about with respect to the other subplans* 
that .they, anticipate. Another important dimension of freedom 
that should be analyzed is the interchangeability of subplans. 
»Hr.s. Jones can drive to town over a variety of equivalent ^ 
routes. The variety is limited only by the condition that they 
S terminate when one of 'her three alternative destinations is 

reached, since only then would the next part of her^ Plan" become 
'••^ relevant. Given a satisfactory Plan and a statement of the 
mobility and substitutability of its subplans, we should then 
be atmr to generate many alternative Plans that are also , 
satisfactory. ^And ws^should like to have ways for deciding 
which combination! -of Plans are most efficient...'. / 

^> x ' [Hille> et al. I960] 

' 2.1. A Ttxonomy of Pla ns ' 

To arrive at a syntax of plans, we begfn\by formulating a taxqnomy of 
planning methods. Figure 1 presents a taxonomy of S^ariety of common planning 
^techniques. We arrived at this taxonomy partly $y Introspect ion , partly 
examining problem solving protocols [Hiller 4 Goldstein 1176b], and partly by 
studying the analyses of problem solving provided by Polya [4957, 1962, 1965; 
1967, 1968]. The taxonomy is incomplete: different domains would emphasis^ 
different planning techniques. Yet there is certainly a. core set.of planning 
techniques common to all domains, 1 

The initial division in the taxonomy is into planning by identification, 
by decomposition and by reformulation. The first category captures those methods 
which tolv4 the problem by identifying it as one which is already known. Thi 
second provides guidelines for breaking the problem into pieces. The third 
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ffeludes. techniques that itttipt to reformulate tht problem into • fori more 
aalonable to Identification or decomposition. 

For. any domain,' there art primitives and previously solved problems? 
Hence, the identification cla**U>reaks into the.se two sub 7 categories. Of course, 
there can be enormous subtlety in how a problem Is recognized as* an Instance of a 
previously solved case. Constructing a taxonomy does not resolve this issue/. In 
COoldstein ft Hiller 1976b] we. introduce formal descriptions of the problem 
domain, and hence can address this issue aore precisely. 

There arVmany decomposition techniques. The taxonomy of figure 1 cites 
only two: decomposition into conjunctive subgoals and decomposition into a 
single subgoal, repeated some number, of ' times. Other decomposition techniques 
•re appropriate for problems that can be decomposed into a disjunctive set of 
subgoals, or into a negation of some goal. Conjunction involves the critical 
question of whether each conjunct can be solved -MUependently .of the others, or~ 
whether thereare interactions. Repetition divides into solution by simple 
iteration of a'slngle subgoal or solution by fujl recursion. 

Reformulation Is perhaps the subtlest of the planning categories. It 
includes finding an equivalent formulation of the problem which presumably is 
easier to solve or a critical simplification whose solution Is a stepping stone 
to the solution of the original problem. Occasionally, one may even reformulate 
/a problem into a stronger form: such as constructing an example when only. an 
'existence proof is required. 

How can we further explore this set of planning concepts? Our first step 
la to be morq explicit about the decision process involved* in ^electing planning 
mmthods from this taxonomy. 



1 » 
2.2. A Planning Graemar * 

> 

We view planning as a "process in which the problem solver selects the 
^appropriate plan type end then cerrles out the subgoals defined by thet plan 
applied to the current problem.' From this viewpoint, the planning taxonomy 
represents e decision Vee of alternative plans. This decision process can hi 
formalised by e context rwe grammar.* A grammar is chosen to present these rules 
because it provides a\i»Pl» «nd coapact represehtatltniXuseful for 
characterising the hierarchical structure of planning. We would not Vgue that a 
context free graamr Is the appropriate formalism for representing a complete 
theory of problem solving elsewhere we employ e more elaborate formalism. 
However, we believe thet the grammar represents a useful abstraction of the 
decision points in- the planning process. 



•S 
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The top level rule in the problem solving 

t 

PI: * SOLVE - ->PLAM ♦ [DEBUG] 9 



graamar^^ 



The nonterminal SOLVE is formally analogous to the* nonterminal SENTENCE in a 
linguistic graamar for parsing or generating sentences. PI states that planning 
is first used to general a pUn, with subsequent debugging then being required 
to complete the solution, pf course, the plan may be entirely correct. For this 
reason, DEBUG is in brackets, indicating that it is an optional constituent ; We 
shall have pore to say about debugging in a later section. 

The placing taxonomy characterizes the planning process as involving 
three mutually exclusive plan categories: identification, decomposition* and 
reformulation. Hence, in pfenning, the problem solver must ehoose among these 
alternatives., We represents this by the disjunctive rule P2. 

»P2: P|,AN / -> IDENTIFY I DECOMPOSE I REFORMULATE 

Now lit us consider the details opeach of these planning categories. 
Identification consisted pf using a primitive or using a previously solvmd 
problea. This is described 1>y P3. 



P3; IDENTIFY -> PRIMITIVE I DEFINED 

The first alternative }eads to the use of primitives from the particular problem' 
doeMin being investigated. 

-r i 

The planning theory is modular, and independent of the application 
doaakn. But it is obviously critical to illustrate its applicability by concrete 
.examples. In this report, we use the Logo elementary graphics programming domain 
as our source of examples. The task in this domain'is to draw pictures with a 
cursor called the, "turtle" by means of programs that move the cursor on the 
screen. Figure 2 illustrates the grammar rules for the primitives of this 
doeMin. Figure 3 illustrates a typical goal undertaken by beginning programmers^ 
a "wish in gwe 11 picture." 

Th* second identification alternative, DEFINED, involves retrieving a 
solution from the library of previously defied solutions and inserting it into 
the current solution. These two steps are captured by the rule P4. 

P4: DEFINED -> USE -CODE ft GET-FILE 1 ? • 

# » 

We now turn to the second major planning category, decomposition. Two 
important decomposition techniques are conjunctive plans, in which the problem is 
sub-Uivided into independent parts, and repetition plans, in which the problem is 
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characterized in ttnu of • sub-problem repeated some number of times. • 

. PS: DEC0NP08E CONJUNCTION | REPETITION 

-Vtf we /to^Lnclude other plans for decomposing problems JjflfcfK as dlsjunctlvo 
plant,. thistle would ba axtandad by adding additional options. 

, tb> taxdnomy shows . con Juhct ion as splitting into two cases: linear an if 
nonlinbir. The 'linear case is intended to represent the . situation wherein the 
.. conjunct s can 1>e solved entirely Independently. The' solution to the original 
problem then becomes- slajply sequencing the, solutions to the aubgoels; or, in 
some cases, executing then in any order, i.e the Independence extends even' to the 
, composition process. Solving for the roots ef a factored polynomial 4s lineal 
(path rooe£can be solved for independently) and the' composition is set structured 
(the order of the solution djes net matter). Solving for the sub-plctures%f the 
wlshingwtll shown eaYlier is independent, * but to obtain theJntJeslred ^relations 
between ttfe parted some specific' sequence must bf established. Rule; P 6 defines 
the two cases for conjuhctlon: 

" •• • » * * 

PS: CONJUNCTION -> flNEAR | NONLINEAR 

• . ' , . > - ... 

Rule P7 specifies the two alternatives for a linear solution: 

■ j^- ,* ' ' _ - ' ' 

' •/ 97: LINEAR . -> SET t SEQ ^ 

P7 \s Incomplete: 'The composition or Independently solved subgoals Bight 
A be In parallel, or via .som Interrupt control structure. A, goal or -our research 
is to 'develop the depth and breadth or {Jit taxonomy and Its associated procedural 
forms so as tj> Include such constructs. 

A sequential plan consists of i sequence or actions, each*consisUnf or a 
■aln step fdllbwed by an optional Interface; these are preceded and followed by 
Npp^nmaJ— setup and cleanup steps. r ' * 

P8i SEQ . -> [SETUP] ♦ <HAINSTEP ♦ [ INTERFACE])" ♦ [CLEANUP] 

* 

The mssence of a sequential plan is that the solutions to the main steps can be 
dear^ • - • — * 



> J|s«nce of a sequential plan is 
Independently of each other. 



* • A' set plan is simpler: the independence of the composition implies that 
no setup or cleanup 'steps are necessary. 

' P9: SET , -> <STEP>"- , * ' 

.For the programming domain, a setup, it In *tep,^nterfece, or cleanup 

_ v; ■.■:<:.*... , " 

\ r * • - ^ • • • • 

O » • JO' v 
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QOAsistsf»f ti.thtr tht addition of a lino of codo or a recursive application of 

amt. 

i 

Plfr: SETUP • -k STEP 

Pit: HA INSTEP -> STEP 

P12j INTERFACE -> STEP . 

P13: CLEANUP r> STEP 

P14: STEP s -> ADD | SOLVE 

• * , j 

Tht ^grammar now Idmits pottntUlly infinitt recursion. What 4s not 
formalized by the context free graver Is the feet thet SOLVE is always attempted 
with respect to. iom% specific problem and in a definite context. Successful 
planning involves sqlvinglRcessively simpler problems until a direct solution 
in terms of the answer library is possible. The semantic and pragmatic 
components, formalized in [Goldstein/ft Hiller 1976b], would constrain tht 
potentially infinite recursion allowed by the gramar. ^ 



Similarly, the grammar does not capture the distinct Jon between a setmq, 
Min step, and cleanup: they are all simply steps.- There is, T howev*r, a 
semantic distinction? For example, the distinction between a main step and a 
setup depends on whether the code is designed to directly accomplish joie subgoal 
a main step; of' to establish some < prerequisite for accomplishing some subgoal 
a setup. For example, ^in the Logo graphics domain, main steps generally 
involve drawing a visible part of the picture while setup steps havrf' the gpal of 
invisibly modifying the. position 1 , or beading of the turtle between adjacent ftiin 
steps. The flyer of t . program [Goldstein 197^) included a program annotator that 
Mde such distinctions by ce ntr ing the picture drawn by the code with a 
predicant .logic description of j^pnded picture. 11 




PIS states that repetition plans can be accomplished either by simple 
loops or by full recursion.* (The latter is not elaborated here.) 

• * 4 « 

P15: REPETITION , ~> ROUND % | RECURSION 

y A round plan is the simple looping case, which ca^ be accomplished eithen by 
iteratipn or by tail-recursion. (Tail-recursi?on is the restricted case wherein 
the recursion Ls constrained to be the last line of the program. It is 
computationally, equivalent to a simple loop structure.) The following rulm 
captures. this: 

P16: ROUND - -> ITER-PLAN | TAIL-RECUR ' ^ 

Figure 4 'illustrates a triangle being accomplished by diVe#^dif f erent 
Logo progrl%>. These correspond to the use of, a sequential plan, a recursive 
round plan and an iterative rouhd plan. The annotations in parentheses, stating 



A 



Grammar Baud Editor 



MMtr U Goldsttln 



I 



Flgwt 4/AccomtHihint A TriiniU 



( (Stqutntltl Plan) 

TO TRI-SCQ 

FO lot : Hal* s/tp — (tcconpHUrlldt ont)- 



•T ltt —Inttrfact Sttp— (prtptrt httdlnp for Hdt two) 

FD 110 Sttp (tccompllih Hdt two) 



* T IM — Inttrftct Sttp— <prtpart htadlnf for slda thrtt)- 

FO 100 Plain Sta#— (tcconpllib ildt thrtt) 

I* **• —Cltamip Sttp (tcconpllih *ttdln§ traniptrtncy)- 



Stqutntltl 
Plan 



tm 



/ 



(Ttll Racurslva l/in) 



TO TRI^tCC 



f (nt stop sttp: dots ntt halt) ! 



FD 10« — Ha1n-*^tH"co«p11ih »*<• «)- 



RT Ut -Inttrfact SttH/ttp. httdlng Hdt r*l)- 
TRI-*tc RtcurHan Stt p 

two 



1 I 
•-St* Pltr 



1 



•— Tt11 
- 1 Rtcurtlvt 
Plan 



(Itarttlvt Plan) 

/ „ 

TO TH1-1TER 

R^IAT | ■ Rtp tat Sttp J ? I 

v • * *-Ittrat1va 

FO ltt -*a1n Sttp (accotiplX^hj^ n) j „-* l pu n 

•-St* P1an-J 

RT ltt —Inttrfact SttM»"P. Haadtaf Hda nflH 
CM 




15 



Greater Based Editor * ~T 11 lilller ft'Goldsieln 

* ' . * * 

what the planning step la Intended to accomplish, ara semantic descriptions not 
Oanaratad^hyJtht gramar^Jfne^raMar oust ba supplemented by semantic 

interpretation ruieeOfi. allwTor such analysis; _ % 

■ Tall racuralon nay bi^capr^antid as a sequential plan plus recursion and 
atop stops. Iteration Is similar. » > . 

* *• * •' ' " ' 

P17: ITER-PUN -> "rapea* stop" ♦ SEQ 

P18: TAIl-REC ^--> SfOP-STfiP ♦ SEQ ♦ REC-STEP • 

P19: REC-STEP -/■recursive propria call* * 

P^fh STOP-STEP .-> 'stop, program "call" 

Reformulation, the thi*8 major planning category, shoult/ be briefly 
■entloned .* figure 3 provldts a slmpla example of reformulation by regrouping the 
parts: a wlshlngwell, originally decomposed Into a roof, a polo and a well. Is 
later viewed as decomposable Into a tree and a well. Reformulation techniques 
depend Intimately onthe problem description. Hence, we do not consider then 
further In this report. The subset of the planning grammar ' employed here la. 



summarised In figure 6. 
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Figure 5 

REFORMULATING- THE WISHINGWELL IN TERMS OF A TREE 



TREE — 




WELL 



■^ROCF 



—POLE 



-WELL 



S.INCE SPADE-0 HAS NO PROBLEM- DESCRIPTION, IT MAY NOT ALWA/S 
BE APPARENT WHEN A REFORMULATION HAS OCCURRED. SOMETIMES IT 
HILL BE APPARENT, THOUGH, PROM TH£ DIALOGUE. FOR EXAMPLE: 

lA. WHAT ARE YpUR SUBGOALS? 

k 

ib. roof, pole j well. 

Za. What 'would you like to do? 
2b. Redo choice 1. 

3a. Choice 1 undone. 

What are your subgoals? 
3b. Tree, well. • • 
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PI: 

fZi 

P3: 

P4: 

PS: 

PS: 

P7: 

P8: 

P9: 

PIS: 

PII: 

P12: 

P13: 

t 

PU: 
PIS: 
P16: 
- P17: 
PIS: 
P19: 
P20: 



SOLVE 
PLAN 
IDENTIFY 
DEFINED 

_ f 

DECOMPOSE 
CONJUNCTION 
LINEAR 
5EQ 
SET 
SETUP 
HA INSTEP . 
INTERFACE 
CLEANUP « 
STEP 

REPETITION 
ROUND 
ITER-PLAN 
TAIL-RECUR 
REC 7 3TjEP 
STOP-STEP 



Figure 6. 02: A Ora— r of Plans 
-> PLAN ♦ [DEBUG] 

-> IDENTIFY | DECOMPOSE | REFORMULATE 
-> PRIMITIVE | DEFINED 
-> USE-CODE ft GET-FILE 
-> CONJUNCTION | REPETITION 
■> LINEAR | NONLINEAR 
-> SET I SEQ 



> [SETUP] ♦ -<HAIN8TEP *[ INTERFACE]) ♦ [CLEANUP]* 



->' <STEP> 
-> STEP' 

v 

T 

-> STEP 

t 

-> STEP 
-> STEP 

-> ADD I SOLVE 
•> ROUND | RECURSION 
-> ITER-PLAN | TAIL-RECUR 
> ■rtpttt ittp* ♦ SEQ 



•> STOP-STEP ♦ SEQ ♦ REC-STEP 

/ 

■> "racurtivt Drograa call* 

t I 

•5 "stop prograi cajA* 



r 
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3, Tht 5PADE Editor 



How ctn we validate • particular grammar? How can wo judge whether the 
ir captures it some level of abstraction the set of planning decisions 
InVblvtd in solving problems for som domain? One traditional methodology for AI 
Is to develop en automated problep solving system. The grammar, however. Is 
Insufficient for this. Semantics and pragma tics are required to makr our theory 
deterministic. (We develop this in [Goldstein ft Mller 1976b].) 



^ But another methodology is possible. This involves incorporating the 
grammar Into in intelligent editing system to augment the capabilities of the 
Hump problem solver. The critical question is whether such an intelligent 
support system successfully aids the user. In this section we design SPME, mm 
editor for defining programs that incorporates our planning grimmer. ^ 



[ 



3.1. 5PADE-0: A Rudimentary Planning Assistant 

The name Structure* Rlinntni uni D*bug§i*i tutor emphasizes^the link 
between the problem solving theory beinq evolved here, and the structured 
programming iovoaent. Dahl, Dijkstra, and Hoare [1972] properly argue for 
program* that /reflect coherently structured problem solving. But ihtfy do not 
develop a theory of planning in any great detail. Our effort in this direction, 
therefore; naturally supplements the examination of programming style initiated 
by Dijkstra end colleagues. j . . % 

Figures 7a ajuTb illustrate |n interaction with 5PADE-9, oqr proposed 
grammar based editor. 12 The user xs interested in defining a Logo program for 
drawing the wishingwell shown earlier. In the SPADE environment, -this is done by 
Applying the planning .grammar in generative mode. The user begins by specifying 
whether the plan is to be an identification, decomposition or reformulation. The 
editor keep! tfack of the pending subgoals, allowing the user to move from one 
goal to another. 



Consider lines 6a and b of the SPADE -0 scenario. 



i 



6a . Do you wish to lnciudo tht optional constituont CLEANUP; i, 
6b. > LATER • 

Those lines illustratt the user' suspending one subgoal, without completing it. In 
order to pursue another. Although SPACE'S default is to suggest subgoals in "tdp 
down" order, the systea will offer the user^ the froodoa to deviate froa this' 
■default, pursuing the set of required goals, in any other order. . The decision as 
to whether • CLEANUP step is needed in the sequential plan Is part of the 



19 



QrwMr, Based Editor Miller ft Goldstein 



Figure 7a. SPADE-0 Scenario (part a) * • 

ffle preliminary persion of SPADE is little more than a ^bookkeeper for the 
user's subgoals. 1jt is currently being implemented'py assigning an in%efpretive 
procedure to iach gramnatical primitive. 

I la. \fait ijk the naae of your top level procedure? 

•'.„.>« . .- • ; 

2a. Unit for Wis: SOLVE -> FLAN' ♦ [DEBUG]. 

Rule for WW-1 is: PLAN ->• IDENTIFY | DECOKPOSE | REFORMULATE. " * 
What now? « 

Zb. >DEC0flPOSE , > 



i • • 

3a Rule for WW-4 is: LINEAR -> SEQUENTIAL | SET. 

What now? ' ^ \ 

3b. > SEQUENTIAL \ v K . 



4a. Rule for WW-5. is: SEQ -> [SETUP] '±jCHMN* t INTERFACE])* ♦ [CLEANUP] 

Do you wish to include the optional constituent ^ETUP? * ' • 

4bi >No ± , . * • * 

/ " + - 

5«l How aany occurrences of <HAIN ♦ [INTERFACE]) do you wantt 
5b. >3 

6a. Jtoyou *lsh to include the optional constituent CLEANUP? 
^_6b. >LATE|t 

LATER is' a Command understood by SPADE. It moans that the>user mints to f 
terminate this path ti but that it must be recommenced later. SPADE keeps.track of* 
^conjunctive ^goals f reminding the user of the pending goal list if asked. Here it 
records the information rewired to return to, and eventually complete, the 
application of the SEQ rule. It can then go on to other goals. 



/ 
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Figure 7b. SPADE -0 Scenario (part b) 



7a. Your ponding goals are POLE, ... and WELL. What NOV? "... 
7b. >POLE " 1 ' v 

SPADE applies the SOLVE.+ule recursively, A 

r . 

8a. Rule for POLE 1$: SOLVE -> PLAN ♦ [DEBUG] 
t , Rule for POLE-1 Is: IDENTIFY | DECOMPOSE | REFORMULATE. 

What now? 
8b. > I DENT I FY 



9a. Rule for POLE-2 Is: IDENTIFY -> PRIMITIVE | DEFINED. 

What now? 
9b. PRIMITIVE 



10a- Rule for POLE-3 Is: PRIMITIVE s -> VECTOR | ROTATION | PENSTATE 

^ What now? 
10b. >VECTOR 



> FORWARD 100 . ^ . 

* 

11a. POLE coaploted. Pending goals are: ROOF, WELL, and WW- 17 (CLEANUP of 

WW). What now? 
lib. >WELL • 



12S. Rule for WELL-1 U: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE. • 

What now? 
.12b. DECOMPOSE 

Here, we have substituted a grammar which contains rules for conjunction but not 
repetgtio*. This- allows Us to illustrate the manner in,.which SPADE avoids 
intemfebating the user when no actual decision Is'reavlred. 

13a. Rule for WELL-4 Is: DECOMPOSE -> CONJUNCTION? 
( Forced . ) 

Rule for WELL-3 Is: CONJUNCTION -> LINEAR | NONLINEAR 
What now? 
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skeleton for the super procedure. (The goal of deciding whether to incluie the 
CLEANUP should not be cortTih^ed with the goal of designing the CLEANUP once the 
need for it has been Established.) Son*, users might prefer to* defer this 
decision until the main; steps have* been further elaborated. SPADE should J>e able 
to accomodate the alternative solution order. * 

The typeout commencing at line 13a illustrates another feature of SPADE* 
0. (A similar sequence is shown at Za.) ' * 

13a. Rule for UELL-4 i^^ECONPOSE -> CONJUNCTION. 
^ (Forced.) 

Rule for VELL-5 is: CONJUNCTION -> LINEAR I NONLINEAR 
What now?- 

Since the grammar is, interpreted (father than being "programmed in"), it is easy 



to try out alternative grammars. Suppose, as is shown here, we employ a 
simplified grammar in which the REPETITION rules havft W^en eliminated. (This 
might be useful in tutoring a novice for example. )* Then no decision is actually 
required in applying the DECOMPOSITION rule. SPADE should notice this, and not 
interrogate the user in such cases. 

Figure 8 illustrates one possible derivation tree for WISHING WELL as 
defined using SPADE-0. T&e utility of this record or the user's design decisions 
*1U become clearer when additional features of SPADE-0 are presented in the 
section on RAID. m 

The Implementation of SPADE-0 (which is now in progress) will not be 
difficult. \ It is simply a bookkeeeping system for applying the planning graaear 
in generative mode to build a solution. The basic implementation technique is to 
provide an interpretive procedure for each grammatical operator (such as M">. 
Additional features-can be implemented by assigning specialist procedures to non* 
terminals of the qfammar, as will be dfene for the debugging assistance 
illustrated later. 



3.2. Towards SPADE- 1. and Beyond 

There is an upper bound on the utility of SPADE-0 which cannot be 
overcome by more careful human engineering. - This is due to the farft that SPADE-0. 
does not have access to a description of th^problem being ( solved . When 
application of the grammar rules results in a recursive application of SOLVE, 
SPADE-0 has no notion of the relationship of the subproblem to the top levml 
Xfloal. To overcome this fundamental limitation, we intend to design and implement 
SPADE- 1. - 



Figufe -3 



ABBREVIATED HIERARCHICAL PLAi^r DERIVATION -FOR A V7ISHINGWELL 

■> / • 

(-SETUP. . . —ID — PRIMITIVE— : ' ' — 



' L 



rUSE-C^DE- 

-MA INSTEP (WELL) ... -ID- DEFINED-[ GET _ FILE . 



-INTERFACE (BETWEEN WELL & POLE)'*. .— DEC. . — LIN — ^^LCLEANUP . LEFT 90 



SOLVE—PLAN— DEC— LIN— SEQ- 



RIGHT 90 



n 



I ' 

CD 
ft 



SQUARE 100 k 
ft 

-GET SQUARE- ° 
FILE 



rMAINSTEP . . . FORWARD 50 



-MAINSTEP (POLE) . . . - ID —PRIMITIVE- 



FORWARD 10C! 



rSETUP... ^LEFT 90 



-INTERFACE (BETWEEN POLE & ROOF) ... -DEC ... -LIN — SEO/-MAINSTE.P .. . FORWARD 50 



UCLEANUP . . 



-RIGHT 120 



3S 



^MAINSTEP (ROOF) . . . —DEFINED. . .* 



0'\ 



-TRIANGLE 10lp * 
& 
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(X 

CO 

ft 
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Figure 9 shows a hypothetical Interaction with SPADE- 1 . In many respects, 
SPADE-1 will be similar to SPADE -fr. Instil l i s governed fryT^et^of context free 
grammar rules, and, still provides bookkeeping facilities for suspending and 
•resuming subgoals. However, SPADE-1 requests that the user supply a formal 
description of the^ problem. (A library of standard problem descriptions is 
supplied for use as building blocks). Th# user need not comply with the request: 
however, without the problem description', SPADE-1 can help oniy as much as SPADE- 
0. ' • 

' With a problem description, SPADE- l-4?quld* be able to provide additional 
assistance. It could notice /when a procedure for solving a subproblem already 
exists in the answer library, by accessing the description of what that procedure 
accomplishes. It could perform rudimentary decompositions, and perform more 
substantial inferences when the user bypasses intermediate step's. Coupled witt\ a 
performance annotation module (such as in [Goldstein 197(4]), SPADE-1 could 
determine (in many cases) whether a given subprocedure satisfies its 
specifications. . ^\ 

The introduction of formal problem descriptions provides a first 
improvement over SPADE-0; introducing pragmatic constraints at choice points in 
the grammar wouldfcprovide a second. This leads to a more elaborate linguistic 
formalism which we briefly consider in the concluding-section. v . 

" \ ♦ 

Whilfc we plan to perform these extensions, from SPADE-0 to SPADE-1 and 
beyond, SPADE-0 will still serve a useful role. The grammar based editor can 
support experiments on several important issues: (1) the adequacy of the 
planning grammar; (2) the domain independence of the planning grammar; (3) tj>e 
utility of the planning grammar in terms of structured programming 
considerations y/ (4) the pedagogical Value of an articulate planning environment. 
* » 
. There is another dimension along which the theory as presented so far is 
incomplete. While the plannintf~rules alone are sufficient to describe programs 
as stat/c, finished objects, they do not capture |he process of defining possible 
Solutions, testing these solutions, and then debugging ttffcm. We n?ed a theory of 
bugs/ and of their diagnosis and repair, to supplement our theory oV plans. This 
is^tne purpose of the next two sections. 
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Flgurt 9. SPADE -1 Scenerlo 



tittk « description of t*« problem, SPADE could *e more *ela/ut. 

% ' 

It. Toll m the MM'of your toplovol procedure? 
lh. >uu *Y • 



\ 



lb. >WW 

2a. Would you like to dtfint a aodel? 
2b. >VI8HINGWELL 



3a. OR. WISHING WELL aodel found In Modal Library. 

Rule for vf-1 it: PLAN -> IDENTIFY. | DECOMPOSE | REFORMULATE. 
What noWT 

3b. >ROOF POLES/ELL , 



/ 



4a. Those subgdals correspond to aodel parts. Are you pursuing a LINEAR 

DECOMPOSITION plan? ( 
4b. >YES \ * 

\ 

5a. The pending subgoals in': ROOF, POLE, WELL and the decisions regarding 

inclusion of preparatory steps (WW-$) for WW. What 'now? 
3b. >ROOF a 

. * 

6a. In the WW aodel, ROOF. is described as a triangle. There" As a TRIANGLE 
procedure in the answer library. Hence, an IDENTIFICATION plan pay , 
succeed. What now? > ■ 

6b. > I DENT I FY 

7a. The TRIANGLE procedure in the answer, library satisfies the intrinsic 
description of ROOF. Would you like to use it? V 

7b. >YES 

8a. OK. The ROOF is coaplete. Your pending goals are POLE, WELL, and WW-5. 
What now? . 

8b. > 



9a. The first order goals for the parts are now coaplete. WW-5 (the choice 
of preparatory steps for WW) is coaplete. You have not expanded the 
definitions for the Interface step, WW-6, nor for the cleanup step, WW- 
8. What now? 
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* ' * ■ * ' 

4. A Oraaaatical Thaorv of Debugging ' 



"K Bugs art so important jtfat it-4s usaful ta classify thea 

and jive the) classes naaef. In real world problea solving wa ^ 
o/ten~gtvj nuts to inporjant classes of bugs. In alactrical 
. engineering, for exaapla, one class .of bug Is •Instability." It 
■ aay%e Ban if est as "theraal runaway" or "spurious oscillation" 

in an aaplifier'. Thik underlying causa is "pQSitive feedback," X 
^ and there* ara several possible curas (patches) which aey ba 
applied: "nagativa feedbedT," or "isolation," for axaapla. 

? V[Sussaan, ^S73, p. 170.] j 

>-In earlier sections, wt constructed a graaaar of planning concepts 'and 
dascribad prograns'as the terainal* strings^ generated by this graaaar. 
Unfortunately, problea stftvers, whethar huaan or aaehina, auit often, decide on a 
plan daspita not only knowledge which is incoaplete or uncertain, but also 
liaitations on t&e and aaaory rasources. Tha hast of choices in such situations ^ 
«an turn out wrongly: debugging is then required. In this section, we follow * 
Sussaan'Sgedvice, developing a- classification of bugs. Ourlgoal in this 
classification scheae is to unify our. approaches to planning an<rdebugging by 
tracing the origin fcf bugs- to various types of erroneous plan#gg choices. la 
section five, we apifty this perspective on possible planning errors to theJdesign ^ 
. of a debugging assistant^lled RAID to be. intqrporated ,into the SPADE 
environment. 




4.1.' Types of Bugs 



Given our perspective on ■planning, 1 ' debugging can be analysed ar tha 
WcalHationr and 'repair of errors in applying the graaaar rules during 
inaration.^ Since our planning rules were constructed froa operators for- 
conjunction, for disjunction and f^ptionality, there arise three basic glasses 



of errors 



4 




(1) syntactic bugs in whiclSthe planning gr.aaaar is violated, 
sucn as when a required conjunct is aissing. 

(2) seacatic bugs in which the plaiH* syntactically • well-f oraeoV 
but soae semantic, constrainOsr.lsins froa the particular 
problea. is violated, such 1 as when a syntactically optional 
constituent, needed because of the seaantics of. the 
pajticifiar problea, is aissing. t . : 

>ragm*tic' hgs In which an inappropriate selection froa a 
sat of autually exclusive disjuncts is aada. 



Grammar Based Editor 1« Billtr * Goldstein 



a This categorization 1$ not complete: two other cl.aj sej^frbugi afY 

•circumlocutions" md "slips of tht tdnowe.- 13 The first class represents jplans 
taalch are successful but inefficient. The second class' refers to miscellaneous 

.errors fn execution including nis-typings, mis-spellings and incorrect * 
programing language syntax that do not. reflect basic conceptual mistakes In the 
•Jan. 

4.2. Syntactic Planning Bugs . , 

^ ' ' \ / 

When 'a decision Bade during a problea solving session violaWs the 
planning grammar, the resultant bug is teraed syntactic. 14 An exaaple of a 
syntactic bug is failure to include an obligatory conjunct. To Illustrate this, 
consider the following eri^r. In the solution oV a problea, one subgoal matches 
a previously solved problea. Hence, the problea solver incorporates a call to \ 
the appropriate subroutine into the solution. But it is common to forget to load/ 
the «Ci la, containing lh«» subroutine into the current workspace. Figure 10 
illustrates this difficulty: as before, the goal is to write a pronraa that . 
draws a wKhlnOwoll. The roof is a triangle, which corresponds to a previously 
defined subprocedure. A call to TRIANGLE is placed In the WW procedure, but WW 
la executed before the ffla containing TRIANGLE is loaded. 19 

In term? of our planning grammar, this is a sgniartic bug. The WW 
procedure is ungraamatical the appropriate rule dosciiblng this situation is: 



P4: DEFINEO . * -> USE-CODE a GET-FILE 

e • 

butfthe file retriev.il is aissing. 

Thus, syntartK bug's are those in which a necessary conjunct of a 
planning rule is not present in the plan. (Syntactic bugs might also be caused 
by the presence 6; an illegal extrn constituent, but this class of problems seems 
less common.) -Normally one *ould not expect a aachine proble't so^vor to make 
this kind of error, givei. >\ correct planning theory and no hnuri.tlc limitations. 
However, resource Halts, on tiae or spece , might resuU in ti ls perf»raance. 
Moreover, it is a exuaon hJm'an etror '* 

Ine basic technique irr repaiiing a "syndetic bug ,onco .isoUced) is to 
redo the culpable planning decision in such a way that the grammar is no longer 
violated. Foi the case of a missingjuit obligatory conjunct, this impales 
solving for the constituent In question, and incorporating that solution into the 
larger solution at the required point. For the WW example in particular, it 
moans getting the. TR1ANG.E proceWj from a fJl*. and then i. -xecuVi g WV *n the 
corrected environment. 
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Figure 10 

DEBUGGING A SYNTACTICALLY INCORRECT PLAN 
: A NECESSARY CONJUNCT 'IS MISSINP 



USE 



TO WW 

10 TRIANGLE — — 

i 

END 

WW GET 
??? TRIANGLE UNDEFINED ??? 



ID-PLAN ' 



("GET" MISSING. UNGIWIKATICAL PLAN, 
'DEBUG BY COMPLETING PLAN.) 



GET TRIANGLE FILE 




\ 



thl int&ndtd pictuJio. 
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4.3. Semantic Planning ggflj 

Semeattc bugs differ froa syntactic J>ug» irTthtt no planning decision 
violatas tha underlying graaaar; rather the usual case is that ■ constituent 
which is optional in the graaaar is nor present, but is needed due to tha 
seaantics of the particular problea. This distinction can be understood -more 
clearly by considering that jf*t«x' supplies broad constraints on the structure of 
solutions to aiT>robieas; semantic* supplies additional constraints in terns of 
features of the particular problea at hand. Rules PI and P8 are typical rules In 
tae graaaar for which this kind of difficulty can arise: 



PI: SOLVE -> V PLAN ♦ [DEBUG,] • 
PS: SEQ -> [SETUP] ♦ <HAINSTEP ♦ [INTERFACE])* ♦ [CLEANUP]. 

Debugging is necessary if the. prograa produced during planning fails to 
accomplish its intended- goals; otherwise, debugging is unnecessary. For a 
concrete example involving PS, let us return to the WW problem Part of the 
problea specification is that tha wishingwell be drawn in an upright position. 
Suppose that the order in which the aain steps are executed is to be: ROOF, 
POLE, and then WELL. The, subprocedure for the TRIANGLE expects the turtle to 
begin at a vertex, oriented along the clrcuaf erence . Therefore, an initial SETUP 
(syntactically optional.) 'rotation is required' to vertically orient the 
wishingwell as a whole. Furthermore, additional interface steps are required to 
establish the required relationship between the ROOF and the POLE, that the POLE 
connect to the ROOF by intersecting with the center of its bottom side. Figure 
H illustrate* this local geoaetry, contrasting a seaantically Incomplete WW 
program t» a corrected version. 

Since it ijj^ofteh 'an effective heuristic to design main steps before 
interfaces, one would pot be surprised if a human programmer designed tha 
subprocedures for the roof, pole. and well, and 'then concatenated ttiea, but forgot 
to include these necessary interfaces. No&eover, even for a machine problea 
solver, there are situations In which it would be more efficient (and therefore 
rational) to determine the need, if any, for such interface steps via trial 
• execution and debugging,' than via thorough but resource-intensive initial 
planning. , C 

In teras of the planning graaaar, the overall plan for the Hjf is 
described es a sequential plan that is, a sequence of aain steps for the parts 
with optional' interfaces. Given rule P8, the WW prograa illustrated by the 
previous figure is syntactically acceptable, but seaantically incomplete. 

Semantic bugs can also occur' when an optional constituent is present, but 

•30 ; 

ERIC 



\ 



Grammar Based Editor 



V 



v Miller & Goldstein 



Figure 11 

DEBUGGING A §EMANT I CALLY ; I NCORRECT PLAN . 



TO WW 
10 WELL 
20^0LE 



• AN OPTIONAL CONJUNCT IS MISSING . 

f 

FOR EXAMPLE: 

"WW" MISSING INITIAL SETUP, 
. AND 'INTERFACE FOR POLE. 



MAINSTEP -i 
MA INSTEP - 



LSEQ-PLAN- 



★ USE IMPERATIVE KNOWLEDGE 
OF MODEL PREDICATES TO 
COMPUTE MISSING STEPST , 




STARTS HERE 



THE SEMANTICALLY CORRECTED PROCEDURE' 



9 
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• TO WW 

★5 WW-SETUP 
10 WELL 



SETUP - 
MAINSTEP H 



★'15. WELL-POLE- INTER - INTERFACE" m 
20 POLE - ",MA INSTEP - 

! ' * -SEQPLAfi 



TO WlrfrSETUP 
10 RIGHT 90 
20 FORWARD 50 
30 RIGHT 90 ■ 
END 



btu SETUP STEP 




STARTS^ 
HERE 



3J 



Oraaaar Rased Editor 18 » Miliar a Goldstein 

. * 

saaantlcally lnappropriatt. An exaaple which we observed in a * high schodl 
studunt was to always* begin » procadura with tha RENUP coaaand, avan whan tha 
firtt Mln stap was to draw a visible vector. This rasultad in aijhar: (a) whan 
tha program was first run, tha first vactor would ba Billing, and than tha PENUP 
would ba dalatad by a dabugging adit; or fb) a PENDOWN coaaand would ba addad to 
tha procadura: inafficiant but otharwisa harulass axtra staps. 

Tha ganaral repair stratagy for saaantic bugs is to redd tha culpable 
planning decision in such a way as to satisfy tha vlolatad saaantic constraints. 
In particular tha repair ^fbr a saaantically incoaplate plan is to solva for tha 
■issing conjuncts and incorporate *thea into tha solution as a whola. For tha 
wlahingwell, this involvas dasignlng setup and interface staps, and than ad it log 
tha WW supsrproca^dura to aaploy thaa. * ■ 

4.4. Prao— tic Planning Bum f 

Soua graaaar rulas dascriba altamativa strategies ta accoaplish a givan 
Plan. . Formally thasa appaar as autually axclusiva dlsjuncts. Exaaplas lncludu: 

1 ■ " ' ' ' 

P2: PLAN -> IDENTIFY J DECOMPOSE | UFOWPJLATE 

P3: IDENTIFY -> PRIHITIVE | DEFINED 

P6: CONJUNCTION -> LINEAR | NONLINEAR 

PIS: REPETITION > -> ROUND | RECURSION 

t 

Fragaattc bugs ara those In which an incorrtfct disjunct is chosan. 
a 

As. an illustration, consldar graaaar rula PoV for conjunctiva plans. It 
specifies two altamativa* for accoaplishing a^sat of subgoals: a linaar and a 
nonlinear stratagy. Now in^this casa, tha formal roles placed by tha altamativa 
dlsjuncts, ara syntactically indistinguishable with respect to tha ovarall 
graaaar. Tha prapaatlc difference, which is ntft formalized htrt, is that a 
linaar dacoaposltion solves for tha sub-problaas independently wh'ile a nonlinaar 
decomposition solvas for scat subgoals givan knowladga of othar subgoals. 

^. In ganaral, linaar plans ara tiaplar to apply bacausa of thair 
independence assuaption . However, .pragaatic bugs arise whan tha plainer is faced 
with a type of problea in which there ar«a inherent interactions between the 
staps. v An example of where linaar problea solving Is inadequate in tha graphics 
world is tha apparently aiaple task of drawing a square inside a triangle (figure 
12). Suppose a linaar plan is pursued. This gives rise to two aain steps (the 
square and tha triangle* and an Interface/ step. If tha aain steps ara solved 
independently of one another (by means of SQUARE and TRIANGLE subpfocedures), It 
Is. likely that .tha figures produced will be of tha wrong size to peralt tha 
daslrad INSIDE relation fc-hold. This violation cannot ba corrected by altering 
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DEBUGGING A PRAGMATICALLY 




—Miller & Goldstein, 

CT PLAN . 



AN INCORRECT DISJUNCT HAS BEEN SELECTED 



TO SQUARE- 1 NS I DE.-TR I ANGLE - 
Id SQUA.RE • 
^20 TRIANGLE • 
END 



( 

LINEAR PLAN -- 
SPG ARB AND TRIANGLE 
DESIRED 
. INDEPENDENTLY. 



INTENDED PICTURE: 




ACTUAL PICTURE 




DEBUG BY CHANGING TO NON-LINEAR PLAN. 
* DESIGN SQUARE IN THE CONTEXT OF TRIANGLE. , 
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the order of composition; nor can it bt repaired by Modifying tha interface. 
-We bug i» pragmatic, in that neither syntax por semantics are violated, but the 
choice of the linear, over the noalineer disjunct nevertheless leads to an. 
■msmccessful plan. 

A pragMtic bug is repaired by redoing the culpable planning decision so 
es to satisfy the violeted pragmatic constraint. (It nay be thet the problem 
solver wa« ignorent of the relevant constreint prior to solving' the currant 
problem, This brings up the setter of.skill acquisition which is deferred till 
, the- concluding section.) In the SQUARE^WITHIN-TRT ANGLE problea, violetion of the 
predicate INSIDE is repeired by changing to a non-linear plan. The second win 
step to be solved Bust be designed-in the context of e per ticuler" size decision 
for the first sain step. For example, the specification for TRIANGLE la changed 
to require that, its side be larger then.e constant which is determined by the 
side length of SQUARE. 
\ 

# 

4.5. 'Circu mlocutions' (Inefficiency Bugs) ' 

/ 

A procedure which solves its specified problem, but in a roundabout 
manner, is seld to have a "circumlocution" or en 1 ae//lcte*cf bug. ' Such 
inefficiencies cen occur fin plens where a' non-optimal disjunct is chosen or an 
unnecessary (but heruldss) optional- constituent is included. Correcting 
Inefficiencies is the typical concern of compiler theory and we do not address It 
. here, except to make the pqlnt thet the hierarchical annotation (or deVivation) 
generated by the grammar is conceivably a useful description for a compiler to 
access. 

* ■ • . 

To illustrate this, consider rational /ofm etotettoaa, the subclass of 
inefficiencies due ^ local oddities in the code,- such es sequential invocations 
of a given primitive." This class *f- inefficiencies has been extensively 
Investigated in the litereture on optimizing compilers. Howevtr, It is possible 
thet such a rationel form violation is due to some serious omission in the 
program; i.e., it it a warning that a bug may exist CGoldstoin 1974]. 
Traditional compilers have no besis for e' Judgment, but access to the planning 
derivation of the program can often illuminate this issue. 

£ 7 

For example, one of the ways in which such en inefficiency bug cen arise 
is from the use of an "evolutlenery" plan [Hiller 1976}. Although thr grammar 
provided in this paper does not attempt to formalize this type of plen, basic 
evolutionery plens ere not complex. The progrumer stteapts to alter the code of 
e previous program to achieve the specif icetlons of e new, but similar, problem. 
To llluktra* such e situetion, however, we must develop e somewhat eleborete 
example/, fPlaasa reexeuftoe figure 3. A wishlngwell, ln*tielly viewed as 
involving three subproblems, has been reformuleted so as to involve two meln 

> » 
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steps, the TREE .and the WELL. The TREE program is state transparent: it loaves 
the turtle in the sane state in which U* started, at the bottom of its fRUNK 
(whiph serves as the POLE of WW). WW incorporates a nonlinearity for efficiency: 
the top side of the WELL is accomplished in two parts, to avoid retracing 
previous vectors. 11 Suppose that the programmer needs ^ SQUARE subprocedure for 
use in another project. One strategy is to adapt WW by deleting the call to TREE 
<figure 13). After' this deletion, though, the resulting SQUARE contains 
sequential calls to FORWARD.: a rational form violation. The optimization is to 
4 coobine these two invocations into a single call to the FORWARD primitive. 

Thus, a compiler could first check whether an evolutionary plan governs 
the inefficiency. If so, it could perform the optimization with some confidence. 
If not, .it should notify the programmer of the oddity in, the code. 



4.6. "Slips of the Tongue" (Execution Errors) 

A final category of bugs is necessary when human programming protocols 
are to be analyzed. This class, "slips of the tongue,* is a catch-all for 
typographical errors, confusions due to orthographic similarity, incorrect 
programming language syntax, noise on the computer line, and other failures to 
successfully type in a statement' of codp. They are often diagnosed b)r 
cqnventional computing environments, simply as a result of the code being 
unrecognizable. The plan is not affected. We include this class for 
completeness, so that our discussions may spah the space of possible bugs. The v 
planning grammar does not provide an explanation for the origins of these bugs. 19 

0 

0 

The general repair technique for slips of the tongue is to: (a) undo the 
side afreets, if any, of the incorrect type-in; and (b) reexecute the type* in 
correctly in the restored environment. This could be captured by a rule such es: 

> REPAIR •> [UNDO] ♦REDO 

A common error in debugging technique is to compound an initial "slip of the 
tongue error* by reexecuting, without undoing undesirable side effects. 20 



Having a classification (ft basic bug types does not solve the debugging 
problem: it is^only a starting point. The flext step is to develop a theory of 
diagnosis and'repair, by which the underlying bug *ad* manifest by en 
unsuccessful program run can be diagnosed, and then repair knowledge associated 
with this bug type can /£e 'applied to correct the program. Soct^ai five'designs 
the RAID assistant that will monitor a programmer during tt\e planning of e 
p^cedure and generate caveats regarding possible errors for aid in subsequent 
debugging. This monitoring will happen within the SPADE editing environment. 
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Figure 13 

DEBUGGING A CIRCUMLOCUTION OR INEFFICIENT PLAN 



TO WW 

5 RIGHT"D0 
1Q FORWARD 50 
20 TREE 
30 FORWARD 50 
40 RIGHT 90 
50 FORWARD 100 
60 RIGHT 90 * 
70 FORWARD 100 
80 RIGHT 90 
90 FORWARD 100. 
END • f 



1 EVOLUTIONARY PU\N 

▼ ^ 



TO SnUARE-1 
5 RIGHT 90 
10 FORWARD 50 
30 FORWARD 50 
40 RIGHT 90 




STARTS HERE J 
ENDS HERE £ 



. )■ 



TREE 




} RATIONAL FORM VIOLATION 



STARTS HERBT 
ENDS /HERE ^ 



SQUARE-1 




END 



CAVEAT DRIVEN DEBUGGING 



TO S0UA"RE : 2 
5 JUGffl 90' 
10 FORWARD 100 
40 RIGHT 90 



' END 

ERIC 



r 



i 



Based Editor 21 Hiller & Goldstein 



8. Tht RAffe Debugging Assistant 

Let us focus on ont particular component of [general heuristic 
knowledge]: the art end techniques of ... debugging. The 
school experience is dominated by. the normative attitude implied 
by "right answer vs. wrong answer". The mathematician *s 
experience ef mathematics, is dominated by the purposeful- 
constrictive attitude Implied by the struggle to "sake it work". 
He abandons an idea not because it happened to go wrong, but 
because he has understood that it is unfixable. Dwelling on 
what went wrong becomes a source of power rather than a piece of 
masochism (as it would appear to most fifth graders in 
traditional Nth classes). ' 

[ Paper t, 1973, p. 10] 

5,1. Diagnosis and Repair 

We have now developed a taxonomy of bug types of what use is it? Its 
first use, we believe, is that it clarifies our understanding of debugging by 
identifying major categories, of error. " Secondly, it suggests how to design 
better debugging aids for the programmer and problem solver. In this section^v 
develop this position by Resigning the RAID component of the SPADE program 
editor. MID Is an acronym for Mtional Implementation of Debugging, stressing 
our belieKtbtt debugging"!* of ten a consequence of heuristically Justifiable 
problem solving, not afPembarrassment indicative of irrational or "sloppy" 
thinking. RAID? is a tool designed to make* debugging a source of power to the 
problem solver, as Papert suggests it can be. 

Let us consider further how the taxonomy clarifies our understanding of 



debugging. A programmer's approach to. debugging is, naturally, colored by the 
diagnostic tools provided by the particular computer system. However, the 
facilities provided by a wide range of computing environments have much in 
common. These tools manifest what we term surface debugging techniques. They 
are based on examination of the code and snapshots of the computational process 
elicited by the code, both relatively superficial descriptions of the procedure 
as conceived by the programmer. Figure 14 shows a grammar which partially 
formalizes this surface debugging activity. 

Access to the problem description and most importantly -- the 
programmer's plen allows for a deeper analysis of debugging strategies. 
Figure 15 shows a taxonomy of these debugging strategies. Figure 16 shows how 
this taxonomy is transformed into what we term a deep debugging groimwr, for 
'contrast with the* previous grammar. Notice that examination of the plan plays art 
important role. 
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Flour* 14. A Surf act Or— Mr For^Dobugnino V " " 



DEBUG -> <[ DIAGNOSE] ♦ [REPAIR]>* 

DIAGNOSE -> <ASK > T < ntACE | "error"/ 

TRACE -> [SELF-DOC*] ♦ RUN* 

SELF-DOC -> ADD- PAUSE t ADD- PRINT* | ADD-TRACE 

ASK -> "print definition" | "print value" | "print flld"| ... 

REPAIR -> <RUN | EDIT | SOLVE>* 

ADD- PAUSE -> ADD v 

ADD-PRINT -> ADD 

ADD-TRACE -> ADD 

EDIT -> ADD | DELETE I CHANGE 

RUM -> "run steteaent of codt" ♦ "response" ♦ [DEBUG] 

ADD t -> "«dd stateatnt of codt" ♦ "response" ♦ [DEBUG] 
DELETE -> "delete steteaent of code" ♦ "response" ♦ [DEBUG] 
-> "change steteaent of code" ♦ "response" ♦ [DEBUG] 



CHANGE 
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FIGURE 15 - A TAXONOMY OF DEBUGGING TECHNIQUES 



.^PARSE-^ADVISE (planning choices) 



DEBUG ' 



DJAGMOSE- 



:ode- 



I PRINTOUT 



— ADVISE (rational form violations) 



/ 



— MODEL — ADVISE (model violations) 



-ASK 



. I — PROCESS- 
US 



TRACE 



-DO 



REPAIR- 



-COMPLETE 



CORRECT 
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Figure 16. A Dt«D Grander For Debugging 




DEBUG 


-> <[DIAGN0SE] ♦ [REPAIR]/ 




DIAGNOSE 


V 

-> < PARSE | CODE | MODEL | PR0CESS>* 




PROCESS 


-> ASK | TRACE | DO 

» 




CODE 


V 

-> PRINJodT | •advise rational font violations 11 




MODEL 


-> "advise Mdel violations' 1 d 


w 

1 


PARSE 


-> "advise heuristic planning choices 9 


t 


REPAIR 


-> COMPLETE | CORRECT 




COMPLETE 


-> "solve for aissing conjunct" 




CORRECT 


9 

-> "choose alternative disjunct" 





V. 



10 
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In the SPADE system, the end product of the interaction is not merely a 
program, but a program annotated by its associated plan derivation (please refer 
to figure 8 presented earlier). The reader has undoubtedly noted that" far more 
interaction would be necessary with SPADE, *th*n with an ordinary editor. 21 - In 
return for this extra planning effort, there are several potential benefits. The 
first ^£s+hat by knowing^the plan, the RAID component of SPADE would generate 
caveats re£ar<|ing possible bugs for aid in subsequent debugging. Since 
definition of. the program generally occupies far less time, than debugging, some 
additional effort in ^nning maxwell be worthwhile in terms of more efficient 
debugging: It is aljo possible that articulating the plan serves to improve a 
student's planning skills. 22 Finally, the plan as commentary should make the 
resulting" code far mope understandable to other programmers who, in large* 
projects, may be expected to modify or debug the package. We have yet to 
consider "human-engineering* aspects in designing SPADE/RAID, nor have wto begun 
t» experiment with it. Here»S^r goal is only to describe those parts of tht 
RAID debugging assistant that ye prfefficated oji our taxonomy of bug types. 



5.2. Aid In Diagnosing Syntactic Bugs 

SPADE provides the facility of being able to suspend the construction of 
* a solution of one fub-problem in order to analyze other goals. This is useful, 
since" occasionally insight into the Solution of other goals Is helpful for 
completing the current problem. SPADE provides bookkeeping 'facilities for this 
"suspension. , The goal can be resumed later. To illustrate this," we shall refer 
tojigur^^ j^ine 3b shows the user chooslnjito postporie a goal. t 

3a. Rul^^t/POLElz is: IDENTIFY -> PRIMTIVE I DEFINED. 
'WhatSrow* — * ' * 



3b. > LATER* 



;, wdiild create a 



RAID, the debugging component, wduld create a caveat each time this 
happens. The caveat would record tht fact that the pUrt is syntactically 
inlompleje at this poipt. k caveat is a demon, which would tri^gtfered by 
premature execution of the procedure being designed. If this occurs, the 
function of the caveat would be to remind the user of the syntactic incorrectness 
of the program. 



3b. >RUN WISHING WELL 



V. 



6a. Running WISHINGWEH. at tbis tiae rtsuiti-in th« bug manifestation: 
UNDEFINED PROCEDURE POLE. 

incomplete: It contains 
repair technique 4* to-. 



^This^is because* WISHING WELL - is sj/ntactically 
'a. the pending subgoal POLE -2. The recoaMnded 
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Fiouro 17. KAlD^lct for Syntactica lly Incomplete Planning Bogs 



U. Which subgoal wojfld, yon Ilka to jforsue? 
lb. >POLE 



3 



/ • 



2a* Rult for POLE-1 Is: PLAN -> IDENTIFY^! 0EC0HP0SE I REFORMULATE . 

What nwT 
2b. MDENTIFY 

3a. Rule Tor POLE-Z 1$: IDENTIFY -> PRIMITIVE I DEFINED. 
^ 1 "What now? 

3b. > LATER. 

7*e LATER command catties further processing of this subgoal to be postponed. 
RAID, the debugging component, creates a caveat each time a LATER comnand occurs. 
r*e caveat record tfte fa£t that this pert of the plan is syntactically 
incomplete at this point. 

4a. POLE-2 postponed. Your pending goal list contains the regaining subgoal 

WELL! Which goal would like to pursue? 
4b-. >WELL- * 



f 



* A 
5a. Wo have now completed the WELL subgoal. What now? 
Sb. >RUN WISHING WELL 

The caveat recorded earlier is a "demon," triggered bg premature execution o/ tfto . 
procedure being designed. If this occurs, the Junction of the caueat isHo 
remind^the user oj the syntactic incorrectness of the program^ 

6a:. Running WISHINGWELL at this tine results In the bug ■anifestatlon: 
UNDEFINED PROCEDURE: POLE. 
This Is because WISHING WELL Is syntactically Incomplete: It contains 
the pending subgoal POLE-2. The recooaendod repair technique is to 
complete the solution of the subgoal POLE-Z. Would you like to work on 

P§-2? ' - \ " 

6b. >Y#R 

7a. You were solving POLE via an IDENTIFICATION plan. You postponed the 
decision (POLE-2) as to which Igswergllbrary to use. 

n The rule for POLE-2 Is: IDENTIFY -> PRIHITIVE I DEFINED. 
What now? 
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coaplote the solution of the subgoel POLE -2. Would you like to work on 
POLE-2? 

Line 6a in the figure illustrates this. 

m 5.3. Aid In Diagnosing Semantic Bugs 

Whenever an optional constituent is rejected, RAID would create a caveat 
to the ef?fcct that the plan My be semantically incorrect at«this point. When 
the program subsequently is executed and bugs occur, the programmer could request 
aid. This aid would include a description of which planning decisions are 
possible semantic errors. This sort of Interaction with SPADE Is illustrated by 
figure 18. > 

Line' lb shows the programmer choosing, to dispense with an optional 
Interface s{ep. 

la. Is there an INTERFACE following WELL? 
lb. >NO 

* 

When the prograa is subsequently tested at line 2b, the programmer it not 
satisfied with the results. 

4b. >ADVISE-PLAN ^ 

5a. WELL may be semantically incomplete. Perhaps an INTERFACE is needed 
after WELL. Woiild you like to reconsider, and include such a step? 

RAID is then depicted pointing -^it that the decision to not include 4n optional 
interface may be the culprit (line 5a). 



5.4. Aid In Diagnosing Pragmatic Bugs ^ 

Certain alternative T planning methods have the relationship that one 
method %% simpler but subject to failure in some cases, While the other 1* more 
complex but more powerful. Examples are LINEAR versus NONLINEAR plan* and ROUND 
versus RECURSIVE plans. "Whenever the user applies the simpler of one of these 
pairs, RAID creates a cavAt to the effect that a commitment to a possibly 
incorrect plan has been made. This caveat serves the same purpose as those 
created above for possible semantic fugs. Upon subsequent execution, if the user 
is unhappy witl\ the results, aid can be requested. The caveat then points out 
possible pragmatic errors. 
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Figure 18. W1D Advi ce For Sa»antlca41y Incomplete PUnnlng Bugs ; 

U. Is thtro «n INTERFACE following WELL? 
lb. >NO 

« 

Whenever an optional constituent U rejected, ■ the MID debugging component 
creates a caveat to the effect that the plan man be semantical ly incomplete at 
this point. 

2a. We, have now coaplatad subgoal WELL. What now? 
— 2b. >RUN WISHINGWELL * 

- « 

Mhen the program subsequently is executed 'and bugs occur, the "programmer can 
reavest aid. This aid includes a description,^ which plannW decisions are 
possible- semantic errors. In this case, the Jp* procedure produces a picture 
which does not satisfy the MSKIWUL model.. tyileJPADE-0 can aid in plan 
diagnosis, it cannot detect model violations without user input. '(SPADt-1, 
however, would perform model diagnosis 

3a. OK. What how? * '.»,;, • *f ^ 
3b. >DIAGNOSE , * * * 

4a. Rule is: ' • . 

- DIAGNOSE -> ADVISE-PLAN { AWISE-CODE | ADVISE- MODEL | ADVISE-PROCESS. 
What now? ' '\** 
4b. >ADVISE-PLAN. ' 

3a. WELL may be semantlc^ly .incompleted Terhaps an INTERFACE la naadad 

. after WELL . Would youfl ike to rectnslder, and Include such a step? V 
5b. >YES * 

6«. Solving for WELL- 13 (INTERFACE? after WELL). 
Rule la: SOLVE -> ... 
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3b. 




6a. 



In designing 8QUARE-WITHIN-TRIANGLE-3, you opted for a LINEAR 
decomposition. It is possible that this problem involves some 
interaction between TRIANGLE and SQUARE. Do you wish to reconsider 
your previous decision, and try a NONLINEAR decomposition? 



Line 6a in the figure shows the RAID component alerting the user to a possible 
pragmatic planning bug. 



The system could do more than Just alert the user to the problem. It 
could also (a) return the user to the suspended goal, and (b) inform the user, by 
means of the grammar; of what alternative constituents are available. Line 7a of 
figure 17 (presented earlier) illustrates this repair as^iatmR^e for the case of 
a syntactic bug. 

7a. You wart solving POLE via an IDENTIFICATION PLXN. You post poo td taa 
decision (POLE-2) as to which answer library to use. 
v the rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 

Suppose the user decides to undo a given planning decision, perhaps 
abandoning a very detailed plan which resulted from considerable effort, in favor 
of a new approach. It is possible that later the user may reconsider, and wish 
to reactivate the abandoned approach. It would be rather unfortunate if RAID had 

erased all records of its existence. In fact, it would not. In order to keep 

* * 

tr^ck of both active and hung alternative versions of each planning decision, 
however, the derivation tree representation ceasas to be adequate. A jpore 
elaborate data structure is required; SPADE/RAID would use a fhart for this 
purpose. The chart data structure was introduced in computational linguistics 
[Hay 1973; Kaplan 1973} to economically store a record of alternative well-formmd 
substrings discovered during sentence parflrig. We Introduce the chart here for 
similar reasons. An example of such a chart applied to the planning context Is 
shown in figure 20; figure 21 shows a user taking" advantage of this capability.. 

The chart data structure provides benefits which feted back Into *he 
planning assistant as well. For example, with the chart one can distinguish 
between using a copy of a previous subprocedure "in line, 0 versus ft sing the 
previous subprocedure as a "black box* which is invoked: 
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Figure 19. RAID Advice For Pragmatically Incorrect Planning Bugs 

« 

\ 

la. Rule for SQUARE -VITHIN-TR IAN8LE- l c is : 

PLAN -> IDENTIFY | DECOMPOSE t REFORMULATE 
What now? 
lfc. >CONJ 



2a.. I have assumed DECOMPOSE -> CONJUNCTION. 
" Aula for 5QUARE-WITHIN-TRIANCLE-3 is: 

CONJUNCTION -/LINEAR J NON-LINEAR. •** 
What now? 
21). >LINEAR • 

.1 

Certain alternative plaining methods hate the relationship that one method is 
simpler but subject to feiture in some cases, while the other is more complex but 
more powerful. Examples are LIHM versus POM LI Mi AH plans and MUHD versus 
JtlCOBSjifi plans. Whenever the user epplies the simpler of one of these pairs, 
WD creates a caveat to tea e//ect teat a cosfcitmsat to a possible incorrect 
plan has been made. 



3a. Rule is 

3b. > i 



4a. Wo havo now completed SQUARE -VITHIN-TRIAN6LE . 
4b.' >RUN SQUARE -WITH IN -TRIANGLE 



What now? 



Upon subsequent execution, if the user is unhappy with the results, aid can be 
requested. The caveat then informs him of possible pragmatic errors. Mere, the 
SQOMi'VITK It-THIAMGLt procedure draws the picture "inside oat." 
* 

Sa. Role is: 

DIAGNOSE -> ADVISE -PLAN | ADVISE -CODE | ADVI5E-H0DEL | ADVISE- PROCESS. 
What now? 
Sb. >ADVISE-PLAN* 



6a. In designing SQUARE -WITHIN-TRIANGLE-3, you' opted for a LINEAR 

decomposition. It is possible that this problem involves sosm 
interaction between TRIANGLE and SQUARE. Do you wish to reconsider 
your previous decision, and try a, NONLINEAR decomposition? 

6b. t >YE3 * 

7a. What non-linear constraint s) do you wish to add to the SQUARE? 
*b\ > * 
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r ! Flour a 21, Returning to. a Previous ly^Hung Plan ] 

^ U. Rula for WW-1 is: PLAN -* IDENTIFY | DECOMPOSE | REFORMULATE 
What now? 
lb. > DECOMPOSE 



/ 

2a. What art your subgoals? 
2b. >ROOF POLE WELL 



3a. Rula for POLE -3 

What now? 
3b. >REDO WW-1 



IDENTIFY •> PRIMITIVE | DEFINED 



Considerable planning effort has been invested in the cutrent version of WW-1. 
The system should tenable to record the state oj the work so far in case it is 
ewer needed again. It might seem too costlg, though, to save emag multiple 
copies of thf.plan derivation everg time a choice is redone,.. 

ij 

4a. Pravious choice on WW-1 undona. 

Rule for WW-1 is: PKAN -> IDENTIFY | DECOMPOSE | REFORMULATE 

What now? ' 
4b. >REFORHULATE 

1 



/ 



5a. What ara your. subgoals? 
5b, >TREE WELL 



C 



6a. Rule is: SEQ -> [SETUP] ♦ <«AINSTEPv* [INTERFACE])* ♦ [CLEANUP] 

What bow? 
6b. >REDO WW-1 



At tats point, the user hit decided to return to the previous approach, finding 
that the REFOAWLATiOM has resulted in an even harder problem. SPADE ' s chart 
representation for plan derivations in fact allows prior versions to be saved, 
vttaout incurring overwhelming storage costs. 

7a. A previously hung version of WW-1 (WW-1: VI) sxlsts, involving a 
DECOMPOSITION plan. Do you wish to raactlvata it? ^ 

7b. >YE3 " 
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Ca. When WW-1: VI was hung, your current goal was POLE-3. 
Rule for POLE -3 is: ... , j tj 
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P4': DEFINED 



•> COPY -CODE | CALL -CODE ft GET-FILE 



Thi rtvistd rult P4' has tht virtue that one can spacify whether future 
changas to tht existing subprocadure should affect the procedure currently being 
solved. If the CALL-CODE disjunct is chosen, the chart will contain only a 
pointer to the shared substructure: future iaprbveaents in the s'ubj>rocedure will 
also benefit the currant procedure. Conversely, future changes could introduce 
unanticipated perturbations. This indicates hew the insights gained fro* a 
gra«atical approach to problem solving can laid to formalizing the origins of 
yet another coaaonly observed source of pregraa bugs. 
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6, Conclusions 
6.1. Limitations and Extensions 
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The ultimate version of SPADE ought to includt • module for providing 
intolligont planning advica and filling in low laval details of 'partially 
specified solutions. However, a contaxt fraa grammar, baing_ inharently non- 
deterainistic, would not suffica as tha basis for a Mchina problem solvar. 
Solving problems by generating all possible derivations and. then testing for a 
solution would hardly be practical. 

There is also a theoretical deficiency. There ought to be a facility for 
skill acquisition: for summarizing previous semantic or pragmatic planning 
errors to prevent their. recurrence on similar problems in the future. Such a 
capability was exhibited by Sussman's [1973] HACKER program for example. But our 
context free grammar has no way of representing repair knowledge in such a way 
that semantic or pragmatic bugs are not repeated. '~ 

Both of these deficiencies can be addressed by moving from the context 
free grammar representation for planning knowledge to an augmented transition 
network [Woods 1970]. Augmented transition networks generalize the context free 
grammar representation. To see the way the ATN serves as a natural 
generalization of the grammar, first examine figure 22. Here we have an 
oquivalant representation for tha G2 planning grammar' as a (non-augmented) 
recursive transition network. The augment** transition network provides several 
generalizations: (1) registers can be provided to store the values of variables; 
(2) predicates can be associated with arcs to control the order of transition; 
and (3) actions can be associated with arcs to build structures during 
transitions. These generalizations were introduced in computational linguistics 
to overcome limitations of the CFG representation that parallel those that wa 
have met in the problem solving realm. Figure 23 is the planning ATN based on 
G2. Some (not all) of the registers, conditions* and actions (for storing anoV 
manipulating information .about the current sub-problem) are shown. Notice how 
greater efficiency can be achieved via techniques such as collapsing states 
moving some information from the topological configuration to the registers— 
(e.g., the CONJUNCTION and SEQ*SET nodes). Figure 24 shows how arc predicates 
can be used to select the appropriate plan type on the basis of features of tha 
problem description. This approach (celled fATK, for PU**in§ ATI) is developed 
at length in [Goldstein ft Killer 1976UJ, Here our goel is only to show how 
repair skill could be acquired by SPADE/RAID by representing planning knowledge 
In an ATN. 

Consider again the SQUARE -WITHIN-TRIANGLE problem discussed in the RAID 
section. Recall that the Underlying cause of the bug was treating the SQUARE and 
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Example Registers : J 
• Register M - Predicate logic tdjKmd?3 C riptio 
Register S - .Current solution, (plan\erivation) 
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Example Conditions: m ^ 

Me Library - "Js problem description matcWd by 
anything in the answer library*" 
^ Generic (M) - "Is the problem description repre- 
sented as a generic element? 

Example Actions : 

tGMGj^ - "Set register {G} to its currem 

tbnteiks jninus subgoab (L t " 
S«-Library(M) - "RetunvW solution founS in 
the answer library." . ; 
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TRIANGLE subgoels as if they were Independent. In fact, 'a second order 
constraint on their sizes was imposed by theMNSIDE^ restriction . Future 
occurrences of this error could be prevented by adding a condition that tests for 
the exis«encej>f thesJNSipE predicate to the arc constraint that governs the 
selection of nonlinear ^Uns. 

Specifically, this is done es follows: figure 29 shows that part of PATN 
that corresponds to the rule, 

P6: CONJUNCTION -> LINEAR | NONLINEAR. . 

y 

. The default arc ordering causes the LINEAR plan to be attempted first. -The*, 
NONLINEAR transition is allowed only if the .NLC or NLD predicates recognize the 
problem as containing a nonlinearity. Here, if INSIDE is present, the NLD loop 
is taken and the problem description modified to make the intefection explicit. 
A; size predicate is added to the description of the parts. Thus, a new arc 
constrain^, NLD-JNSIDE, serves to prevent this particular pragmatic planning 
error from happening again. 

U 

6.2. Applications • 
• * * • 

These ideas lend themselves to a variety of application*. We consider 
thrfre: automatic programing, automatic protocol analysis, and structured 
programing. / 

As semantic and pragmatic capabilities are added to SPADE (reflected by 
the increasing role of PATN in providing advice), the user would be consulted on 
progressively fewer planning decisions. The ultimate extension in this direction 
if of course for SPADE to request no guidance at all from the user. The user 
would supply the problem description; SPADE would provide the solution 
procedure. One novel aspect of this approach to automatic programming is 
; methodological: the SPADE series of systems provides an implementation strategy 
based on incremental simulation [Woods a Nakhoul 1973]. " 

r ^\ l Automatic programming is an extension of SPADE in a direction in which 

the user is pushed toward the higher level planning decisions, whereas the system . 
perform* more of the lower level choice*. Exploration in the opposite direction 
is also possible; in the extreme this amounts to protocol analysis. Suppose 
that the problem solving of a SPADE user is running far ahead of the system: the 
user may wish to type in code directly, rather than laboriously detailing the 
'intermediate steps of the plan. The system's Job then .becomes linking the low 
level event into a higher level, planning structure, If every .event typed by the 
user were at this cod% level, SPADE would 1 - superficially be serving as a 
conventional editing environment. The difference would lie in the assistance 
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possiblt during subsequent dabugging. Ideally, SPADE woftd have a nodule (which 
wa call PAZATM, for Protocol AaelZer based on an ATM) for inferring the user'* 
•lea and wotld therefore be able to support our deeper notion of debugging 
•von when the plan is only implicit. Figure 26 illustrates how • hypothetical 
version of the SPADE systea, augmented by PAZATN, could significantly reduce the 
aaount of interaction required to . articulate the planning knowledge 03 veil as 
tae code for use by the systea. [Hiller a Goldstein 1976d] takes a aore careful 
look, at the difficulties which the PAZATN aodule aust face, and presents a 
aroliainary design. •> 

\ 

A final application is to prescribe improved programing methodology. 
The antira enterprise embodies Dijkstra's philosophy of programming in a 
structurad fashion. Moreover, it raprasants a moKe datailod study of planning 
and dabugging tachniqfcs than has previously been attempted. It indicates how 
intaractiva editors can 'strongly arrcouraga coherently structurad articulate 
planning,, Tha uijderly^a^heory provides an analysis of tha neVtur* aiTd Qjrigin of 
bugs, suggesting which sorts <f bugs can be avoided by improved design, and wh.'ch 
arisa from Justifiable heuristic choices. The occurrence of such uncertain 
choices however, can' i>e recorded, leading to bookkeeping and diagnostic 
capabilities such as^those planned for RAID. Batter dabugging advice ~ going 
beyond caveat:, for potentitfl difficulties — Mist await the incorporation of PATH 
(enVto som extent PAZATN) *nto SPADE. 

(This report has presented a unified theary of planning end debugging 
based <fr a linguistic analogy. Tha design of an intaractiva programming 
environment hab also been described. The. objectives for this programing 
environment, SPADE, are 'net serve, not only as a practical application of the 
theory, but also as an experimental crucible for tasting claips of the theory, ^ 



We expect tha: experimentation with SPADE will yield the following kinds 
of information: (a> hi 3vidence regarding the heuristic adequacy of the planning 
taxonomy and grammar* b) psychological evidence regarding the utility of the 
grammatical formalism z% a modeling tool, for characterizing varying skill 
levels, in tprms of j#hich .subsets of the grammar are used successfully and 
unsuccessfully; (c) compute*- science evidence regarding the efficacy of 
alternative documentation standards and design methodologies; and (d) 
pedagogical evidence > egarding the value for a learner of programming in this 
type of articulate environment. 
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Figure 26. A Scenario Illustrating SftADE Augtntfd by PAZATN 

la. Wt are now solving for a WISHING WELL. Your pending subgoa Is are ROOF. 

POLE, WELL, and the interfaces. What now? 
lb. > SOU ARE 

fere tJbe user types in ah event at level of the actual code. The proper 
inference Is tAat tAe user is, sol ving for VELL using an IDENTIFICATION plan. 
SQUARE is presumably in the user-defined answer library. 

2a. OK. I as assuaing that WELL has been solved by IDENTIFY lng it with the 

previously solved SQUARE procedure. What now? 
2b. >FORWARD 100 * 

# 

Again, the user has typed in a very lorn-level event which requires careful < 
interpretation. There are a number of vector .commands which might be expected 
synthetically. For example, this could be the interface between the VELL and the 

w POLE. Nomever, if the SQUARE used for the VELL is of size 100 ; then FORUARD 199 
worn Id be too large. Also, a preparatory rotation would have bqen needed. The 
vector might also be a side of the TRIANGLE for the ROOF. Bowever, if TRIANGLE 

. is already in the answer library, an identification would be expected, not a nem 
solution. Probably, this vectof accomplishes the text main step in PATN's* 
default solution order: POLE. However, PAZATN can employ a demon to pbstpone e 
final commitment until further evidence arrives. 

3a. OK. tihat now? . * 

3A. >TRIANGLE * ^ 



4q. OK/ I guess ROOF has been solved by IDENTIFICATION with the, existing 

TRIANGLE. So the FORWARD 100 must be the POLE. Your only remaining 
subgoals are the interfaces. Vhich interface would you like to solve? 

A. 



It ti worth noticing how few user type-ins have been required in this dialogue — 
fewer than even in conventional code — yet the solution for the VISHINGVELL is 
almost complete. Moreover, the system has inferred not only the code, but a 
rather thorough description of the user's plan as well. This economy of 
Interaction would be achievable by the combination of SPADE, PATN t and PAZATN 
enabling the user to focus on the few critical planning choices that more or less 
force the reminder of* the solution. * 
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1. While there Is torn* over lip, our objectives for SPADE dlfftr In toll 
respect froa tht objectives of those working to construct protrtmUmg apprentices 
[Toltolman 1970,1974; Hewitt ft 3.1th 1975; Rich ft Shrobe 1973]. It Is too early, 
however, for e detalled^comparlson of either goals or methods. 

2. Thevirtues of the Logo graphics world [Papert 1971a, b;., 1973]. are: 
(#)_Braphlcs Is an environment In which Multiple problem descriptions art 
possible, ranging from Euclldeen geometry to Certeslan geometry; (b) the 
possible progress renge over e wide spectrua of coaplexity; and (*) there Is 
extensive docuaentatlon on human perforaance In this area [0. Goldstein 1973: 
Okuaura 1973]. 

3. These task doaains.are natural candidates for testing the generellty 
of the theory^. The blocks world Is a benchmark AI doaaln which provides a 
yardstick against which to aessure the progress of our approach. The set theory 
world has the virtues of both Intrinsic Interest and straightforward semantics. 
The creation of programs eabodylng ^concrete realizations of set theoretic 
constructs Is a standard programming task. Similar remarks are appropriate for 
the doaaln of programming an elementary calculator, such as to parfora routine 
statistical analyses. 



4. In [Goldstein ft HlUer 1976a] we presented a scenario for • 
programming tutor called Sherlbck^One extension of the SPADE system presented 
here is toward such alxetf-Uitif tire AI based personel leemlng environments. At 
the same time, the SPADE style of lnterectlon" suggests a more structured 
elternatlve approach. Whether the additional structure is desirable for seam (or 
moot) students Is am empirical question to be addressed In future research. 

3. In [Killer ft Goldstein 1976b] we presented^ different version (01) of 
the planning taxonomy and grammar, in the context of parsing a student protocol. 
Our_ reasons for abandoning that version in favor of the current one should be 
discussed. The earlier taxonomy was based on examining the directions from which 
a planner could obtain guidance: looking upward to general principles, downward 
to domain specific heuristics, forward to anticipated needs, and backwards to 
previously solved problems. The current taxonomy derives from exaattilngUhe 
logistic description of the current problea. The former taxonomy emphasized the 
roles of experimentation and uses of past problems; waerea^e current one 
treat* these as details, some of which (such as experimental^) remain to be 
addressed. It remains true thet decomposition techniques can very along 
dimensions of domain specificity and generellty. However, In some cases we found 
the earlier taxonomy to be problematic. As we began to Incorporate septic and 
pragmatic- constraints on the_ grammar (see [Goldstein ft Hlller 1976b]), it became 

■HZ 9 

O f 

ERIC 



Gj-MMr Bastd Editor 



30 



Hill-er ft Goldstein 



increasingly difficult to maintain t fonMl distinction between certain examples 
of domain dependent and evolutional^ plans. There is of course a trade-off in 
assigning knowledge to the syntactic rules, as opposed to assignTftg it to 
semantic or pragmatic constraints on their aptflication. In order to jiktify a 
claim that the current version of the taxonomy is aore parsimonious than the 
previous one, we would need to carefully identify the corpus of data. While we 
do, in fact, believe that the current version is more elegant, the grounds for 
this belief remain intuitive. In . subsequent research we intend to employ the 
SPADE system as an experimental vehicle for contrasting alternative planning 
taxonomies and their corresponding grammars. 

6. The statement that there is a core set of planning techniques common 
to all domains is Justified by examining the formal basis for the taxonomy. On 
the assumption that problem descriptions are represented as predicate calculus 
statements, It is. clear that solution can proceed by: (1) Identifying the 
statement as one for which a solution procedure is known to exist; (2) 
decomposing the jyoblem into subproblems on the basis of the top level logistic 
operator; or (3) reformulating the problem description such' as by theorem 
proving techniques. That is, domain independence of the core set of planning 
techniques holds, on a priori grounds, to the same extent that problems in the 
domain are doscribable using predicate calculus problem descriptions. 

Of course this argument depends on the efficacy of the first order 
predicate calculus as a problem description language. While we are not prepared 
to argue for this here/ it is clear that the calculus certainly has had some 
success in the past (e.-g. in mathematics) and hance is an obvious candidate: Its 
frequently observed deficiencies, such as nop-directed inferencing, are discussed 
in [Goldstein ft Hiller 1976b], where we define a procedural problem solver 
organized around logical operators. It is also important to recognize that we 
are not arguing for. uniform- (e.g. , retol* ttoa-based) theorem prover style 
programing techniques. - 

Moreover, extensions of the predicate calculus, such as higher-order 
calculi, do not obviate the need for basic problem solving techniques for dealing 
with conjunction, disjunction, negation, and quantification. ' * 

7. This view of planning is a simplification. It Asserts that the 
problem is analyzed . in a top down fashion. Of cowse, the problem solver can 
engage in exploration and experimentation; or can identify a subgoal without 
having a clear understanding of the overall plan. The dynamics of exploration 
are not formalized by this grammar. 

•* , ' • * 

8. Our use of a context free grammar for problem solving closfly 
resembles D. Rumelhart's [1975] work on story gratturs. It should be interesting 
to see to what extent our respective theories, designed to account for 
superficially very different phenomena, continue to develop in parallel. Would 

it be useful, for instance, to define a set of sMmnriz* tio* rules (such as those 

j 
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•ployed by Rumelhart) to describe the plannilto process? One possible set of 
plan summarization rules would focus on the SOttfc nodes, suppressing printout for 
nodes of other types. Conceivably, thU could be useful in highlighting the 
smbprocedure organization. ~~~ 

9. The rules of the grammar ere written using the following syntax: 



disjunction: 



ordered conjunction: 



•e I b' is reed as, "a or b"; 

•a ♦ b m is read as, 'a andb^, 

wher^the order Is significant; 



unordered conjunction: *a ft b" is read as, "a and b", 

_ where the order is insignificant; 



.optionality: 
iteration: 

lexical category: 




•[a]" is read as, "a is optional"; 

s 

■<a>*.* is read as, 

*a repeated 1 or acre times"; . 

e lower case English phrase enclosed in 
quotation marks (e.g., "number") 
describes a lexical itea which is not 
further expanded in the graaaar. 



10. The ft operator is used, because the GET and USE can occur in aay 
order as long as they both precede execution of the procedure being defined. 

11. While the Hycroft systea designed by Goldstein was potentially 
capable of semantic annotation, it lacked a clear formalization of the range of 
possible plenning choices a prograa designer could aeka r and a description of 
possible' errors in terms of Hhese design decisions. The grammar we present here 
is intended to address these limitations. 

12. The interactions presented here are hypothetical dialogues with a 
systea which has not been iapleaented. .Although a crude preliainary 
implementation (SPADE-00). has recently begun, it is currently lacking several 
essential features. 

One deficiency "of SPADE-00 is that it has not been interfaced with LLOOO 
[Goldstein et. al. 1974]; hence it is not possible to actually execute the 
resulting ; prograas. Another deficiency is that the RAID features described . in a 
later section have not yet been coded. 

The purpose of presenting typothetical dialogues, rather than actual 
transcripts, is to enable the rttdek- to focus on the content, without being- 
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sidetracked ^ by details concerning the inadequacies of the implementation. 
Readers Mho have eccess to the laboratory's timesharing system, are nonetheless 
Invited to experiment with our trial versions of SPADE as follows. After logging 
in, type :5PADE<cr>« tNSPADE. will generally be a newer, highly experinental 
version. :OSPADE will be an older version, in case of disestrous naif unction ing 
by :5PADE. 

SPADE-00 simplifies the interaction by employing e "menu" or "multiple 
choice" style: 

WHAT WOULD YQU LIKE TO DO? ft 
■A -- IDENTIFY ' ^ 

■B -- DECOMPOSE ) 
■C -- REFORMULATE . 

>«a " 

*■ _ 

Certain operetions, such 'as the LATER capability, are implemented as speciel 
"escape commands," in order to reduce ambiguity and simplify parsing. For 
example: 

i 

Hater 

. I DON'T UNDERSTAND: LATER. 
>fleter 

POLE POSTPONED. 

Once started, the system is self-documenting, end is gradually becoming 
friendlier ,to use. Suggestions and bug messages mey be .sent via the system 
mailer' to SPADEWUT-AI. - 

13. The question arises as to whether the bug taxonomy is exhaustive when 
circumlocutions and *lips of the tongue are also included. In a trivial sense, 
the answer is "yes" btcausfc ^e latter class is open-ended by definition. In a 
deeper sense/ the answer may also be "yes" in that no bugs need ever be assigned 
to this category which violate our intuitive requirement that the underlying plan 
not be affected. This is a hypothesis which we tentatively accept but cannot 
prove. 

14. To avoid possible tonTusion, it should be stressed that our bug v 
classification does not corresponcUto jthe usutl terminology of programing J.or*. 
While there is a slight analogyyJU *kf be misleading. That is. "syntactic 
planning bugs" does not refer t& tliVsyntax of the programing language; it 
refers to the hierarchical structure of the jrottess of constructing programs. 
Similar remarks are in order for semantic and pragmatic planning bugs. For 
brevity, we hay use the shorter. phrases, e.g., "syntactic bug," to refer to a 
syntactic planning bug. For the. most part, we are not concerned here with syntax 
errors (or "semantic errors") In the usual sense. 



65 



r 



\ 4 



••sad Editor 33 Hilltr * Goldstein 

m r\ 

15. A natural objaction is that this particular bug could be elininated 

. if tha coaputing environment wars aodified so as to autoaatically load ^ 
appropptata-f lias whan naadad. Wa coaplataly agree, Indaad, it illustrates tha 
poinf that tha graaaar illuainatas tha dasign of iaprovad coaputing anvironaants. 
It i\no way altars tha obsarvation that, givan any particular coaputing 
environlent, cartain syntactic constraints on tha structure of programing plans 
aust ba adharad to, nor that violation of thasa constraints constitutas ona typa -a- 
of arror. 

• • <• 

16. Of course, the issue arises as to whether the huaan p rob lea solver is 
■ slaply Tor getting part of a known rule, or is unaware of tffe rule in the proper 

fora. This leads to a set of difficult probleas in protocol analysis surrounding 
tha hypothesizing of the graaaar underlying a givan individual's problea solving. 
This topic is pursued in [Hilltr ft Goldstein 1976b, d]. 

17. The occurrence of two consecutive calls to a given priaitive is odd 
when a single invocation, perhaps with altered input, will suffice. In Logo, two 
adjacent PENUP coaaands, or two adjacent FORWARD instructions would be considered 
rational fora violations. 

' 18. This wishingwell pi%jraa eaploys what Goldstein [1974] teraed ah 
"insertion plan." The TREE shown here is inefficient in that it achieves state 
transparency via "rwfacing the TRUNK. There is also a tradeoff in the WELL '. ^ 
batwaen aodularlty and efficiency. The use of the insertion plan to avoid 
ra tracing on tha top side of the WELL results In lass aodular eodaC These points 
are noted only to avoid aisunderstanding they have no bearing dn the thrust of 
tha exaapla. ~J 

19. 'Viewing debugging froa the Vantage point of this taxonoay sheds soaa 
light on the issue of the pedagogical value of various kinds of bugs. Our 
current understanding of the first three (and to afpa extent the fourth) 
categories of bugs suggests that encounters with 1 such bugs aay be instructive in 
teaching planning as well as debugging. However, "Sips of the tongue" at best 
provide *oae exercise in bug localization. Hence, a "forgiving" systea that 
ainiaizes the penalties for such low level bugs is probably pedagogically .sound. 
The best exaapla of this philosophy is tha Interllsp DVIH (Do Met / Hean) 
facility [Teitelman 1970,1974]. (By contrast, our effort to Bake Bore of tha 
Pioa explicit Bight be called SHIH, i.e*., Say Met / ffeea!) 



20. If we define a context free graaaar for debugging,, then this error in 
debugging technique can ba classified. For exaapla-, if the rule of the debugging 
graaaar for fixing slips of the tongue isr^ 



REPAIR ~-> [UNDO] ♦ REDO 
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where undoing is optional since It Is not always required, then the error of 
failure to undo (due to forgetting or to confusion regarding the existence of 
side effects) Is sertntic. 

An alternative view of debugging would be to characterize planning as a 
context free graeear, while debugging is described as a trani/ormatlonal 
coffconent that naps , derivation trees, to derivation trees. This would be 
theoretically elegant, and this possibility deserves further study. Howeiver, 
resolution of this Issue goes beyond the current paper. 

21. Later we briefly introduce r nodule we are designing called PAZATO 
which would help* to alleviate this difficulty. PAZATN would be <apable of 
parsing progressing protocols, Inferring -« fro» a combination of synthetic 
expectations and analytic evidence - which plans had been used. 

<v 22. A fundamental hypothesis of the Logo project is that children learn 
by doing and thinking about what they do. One of our purposes" in implementing 
the SPADf editor is to explore this hypothesis by experimenting with the relative 
merits of -SPADE versus the traditional Logo programming environment. In SPADE, 
the student is required to be articulate. Whether this helps students to master 
planning and debugging concepts more quickly — or hinders them remains to be 
seen. * Our conjecture is ^ that despite the exf>a interaction demanded, 'students 
will find the need ta^fee articulate about their' problem solving a' significant 
help In learning, Js measured by en ability to solve harder problems more 
quickly. 
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